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REMARKS 

Claims 1-15, 20, and 23-27 are pending. Claims 1, 10, 12, 20, and 26 have been 
amended to clarify the claimed subject matter and not for any reason of patentability. 
Applicant respectfully requests reconsideration and allowance of this application. 

Rejections under 35 USC § 112 

Claims 1, 10, 12, 20, and 26 stand rejected under 35 U.S.C. § 1 12, first paragraph, as 
failing to comply with the written description requirement. The rejection asserts that the 
claim(s) contain subject matter which was not described in the specification in such a way as 
to reasonably convey to one skilled in the relevant art that the inventor(s), at the time the 
application was filed, had possession of the claimed invention. The rejection further asserts 
that Claims 1, 10, 12, 20, and 26 recite the limitation "producing a network latency similar to 
the clients" and that the cited limitation is not described in the specification. 

Claims 1, 10, 12, 20, and 26 have been amended and do not recite the limitation 
"producing a network latency similar to the clients". The amendment also clarifies that the 
load balancing domain name servers (DNS-LBs) of the claimed subject matter are deployed 
in a proximity from which the actual network latency of a client connecting through an ISP 
may be measured. Support for these amendments may be found at page 5, line 21 - page 6, 
line 5 of the specification, which discloses: 

While several companies have developed 
mechanisms to provide some form of global load 
balancing, none of these current systems measure actual 
network latency from physical locations close to the 
various clients. As a result, a particular client may be 
directed to a particular web server when, in fact, a different 
web server may have smaller latencies and give better 
performance from the client's physical location. 

The system and infrastructure of the instant 
invention overcome this problem by performing global load 
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balancing from physical locations in close proximity to the 
actual client. 

The above-cited section of the specification discloses that the system and 
infrastructure of the presently claimed subject matter overcomes the problem of not being 
able to measure actual network latency from physical locations close to the various clients by 
performing global load balancing from physical locations in close proximity to the actual 
client. That is, the purpose of placing the load balancing domain name server (DNS-LB) in 
close proximity to the actual client is to measure the actual network latency of the client. 

Claims 1, 10, 12, 20, and 26 are rejected under 35 U.S.C. § 1 12, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the subject matter 
which the Applicant regards as the invention. The rejection under 35 U.S.C. § 1 12, second 
paragraph, asserts that the phrase "similar to" included in Claims 1, 10, 12, 20, and 26 
renders the claim(s) indefinite because the claim(s) include(s) elements not actually disclosed 
(those encompassed by "similar"), thereby rendering the scope of the claim(s) 
unascertainable. Claims 1, 10, 12, 20, and 26 have been amended to clarify the claimed 
subject matter and no longer recite the phrase "similar to". Accordingly, the rejection under 
35 U.S.C. § 1 12, second paragraph, is now moot. 

Rejections under 35 USC 103(a) - He and Skene 

Claims 1-16 and 20 and 23-27 stand rejected under 35 U.S.C. 103(a) as being 
anticipated by He et al. (U. S. Patent Number 6,671,259) (hereinafter "the He reference") in 
view of Zisapel et al. (U. S. Patent Application Pub. No. US 2005/0022203 Al) (hereinafter 
"Zisapel"). 

The Applicant respectfully traverses this rejection as the rejection fails to establish a 
prima facie case of obviousness, as set forth in MPEP §2143, which states, in part: 
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To establish a prima facie case of obviousness, 
three basic criteria must be met. First, there must be some 
suggestion or motivation, either in the references 
themselves or in the knowledge generally available to one 
of ordinary skill in the art, to modify the reference or to 
combine reference teachings. Second, there must be a 
reasonable expectation of success. Finally, the prior art 
reference (or references when combined) must teach or 
suggest all the claim limitations. 

In general, the He reference is directed to a simple system and method for load 

balancing where a client is directed to a load balancing server based on one criteria of a 

predetermined set of criteria. He also discloses that "the load balancing system and method is 

not limited to a specific location on the network" (see He, column 2, lines 9-10). Further, 

Zisapel is directed to a simple method for load balancing where a load balancer redirects a 

request from a client if the load balancer includes a record indicating that a different load 

balancer is appropriate for the client. 

The rejection to Claim 1 asserts that He teaches all the limitations of Claim 1 with 
the exception being that He "fails to teach wherein the DNS are placed in physical proximity 
producing network latency similar to the client". The rejection also asserts that Zisapel 
teaches "load balancing system", and further, "Zisapel et al teaches wherein the clients are 
placed in physical proximity with the DNS and sending mapping information relating the IP 
address" at page 3, paragraph [0036]-[0038]. 

Claim 1 has been amended and does not recite the limitation "the DNS are placed in 
physical proximity producing network latency similar to the client". Rather, Claim 1 recites 
"a physical proximity from which the actual network latency of the clients may be 
measured". Regardless, assuming the rejection asserts that the "triangulation mapping table 
32" relates to the physical proximity between a load balancing server and a client, this is not 
taught by Zisapel. Rather, Zisapel teaches "[i]t is a particular feature of the present invention 
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for LB2 to designate a currently unused virtual IP address, such as 200.100.1.1, for LBl's use 
and store the mapping between the IP address of LB 1 and the designated IP address in a 
triangulation mapping table 32". To wit, the triangulation mapping table of Zisapel does not 
store any physical proximity information; in contrast, the triangulation mapping table of 
Zisapel stores a mapping between the IP address of a first load balancing server and a 
currently unused virtual IP address. A virtual IP address is virtual and does not correspond to 
a physical location or proximity to a physical location. 

The rejection further asserts that it would have been obvious to modify He in view of 
Zisapel "in order [to] indicate subnets and the best server farm site or sites to which requests 
from a particular subnet should be routed". Such an assertion fails to establish a prima facie 
case of obviousness as there is no suggestion or motivation within He to suggest one of 
ordinary skill in the art would be motivated to combine He with Zisapel or modify He in view 
of Zisapel. Consider that He does not discuss subnets, server farms and that He is already 
directed to indicating "the best" or "optimal" server where requests should be routed. For 
example, see He, column 1, lines 66 - column 2, line 3: 

"[i]n order to reduce or regulate this server 
congestion, the present invention provides a load balancing 
system and method which distributes the client request to 
different servers on the WAN by selecting the most optimal 
server for a specific client request." {emphasis added) 

Also consider that the disclosure of He encompasses subnets, as subnets are by 

definition included within a network. That is, the disclosure of He already includes 

functionality to" indicate subnets and the best server farm site or sites to which requests from 

a particular subnet should be routed" and the combination of the teachings of Zisapel would 

only add redundant functionality to He. Therefore, it is not reasonable to suggest any level of 

success in combining He and Zisapel as Zisapel offers no new functionality to He. 
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The Applicant respectfully submits that neither He nor Zisapel, either alone or in 
combination, disclose the limitations of Independent Claim 1. The Applicant also submits 
that because the rejections to Independent Claims 10, 12, 20, 23, and 26 are made using the 
same rationale as the rejection to Independent Claim 1, Independent Claims 10, 12, 20, 23, 
and 26 are also allowable for least the reasons discussed with respect to Independent Claim 
1. Therefore, the Applicant respectfully requests that the rejections to Independent Claims 1, 
10, 12, 20, 23, and 26 be reconsidered and withdrawn. 

Furthermore, Claims 2-9 depend from Independent Claim 1, and therefore Claims 2- 
9 are also allowable for as least the above noted reasons. Claim 11 depends from Claim 10, 
and therefore Claim 11 is also allowable for as least the above-noted reasons. Claims 13-15 
depend from Claim 12, and Claims 13-15 are also allowable for as least the above-noted 
reasons. Claims 24-25 depend from Claim 20, and Claims 24-25 are also allowable for at 
least the above-noted reasons. Claim 27 depends from Claim 26 and is also allowable for at 
least the above noted reasons. 
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Conclusion 

In view of the amendments and the remarks above, Applicant respectfully submits 
that this case is in condition for allowance and such allowance is earnestly solicited. In the 
event that there are any outstanding matters remaining in the above-identified application, the 
Office is invited to contact the undersigned to discuss this application. 

Respectfully submitted, 
MICROSOFT CORPORATION 



Date: 02/26/2007 By /James R. Banowskv / 

James R. Banowsky 

Registration No. 37,773 

Direct Phone No. (425)705-3539 



CERTIFICATE OF MAILING OR TRANSMISSION 
(Under 37 CFR § 1.8(a)) or ELECTRONIC FILING 

I hereby certify that this correspondence is being electronically deposited with the USPTO via 
EFS-Web on the date shown below: 



February 26, 2007 /Kate Marochkina/ 

Date Signature 

Kate Marochkina 



Printed Name 



Page 14 of 14 



